Identify Potential Accessibility Issues in Design Systems
On this page
The following design review challenges aim to get you thinking about potential accessibility issues when reviewing design systems, mockups, layouts, and components.
These 3 challenges will also provide the opportunity to practice structuring feedback and highlighting accessibility problems before they get baked into implementations.
The images will be provided below but they can also be found in the workshop repository.
Let's do some design review!
Install Colour Contrast Analyser
Colour Contrast Analyser (CCA) is a free color contrast checker tool that allows you to easily determine the contrast ratio of two colors using an eyedropper tool.
This desktop application works anywhere on your screen–not just the web browser. You could sample colors on a website, in a PDF, or even in a screen share over Zoom (for a rough idea, at least)!
WCAG Color Contrast Guidelines
When designing readable interfaces for varied color perception, the WCAG 2 guidelines recommend the following contrast ratios:
- Body text: with a minimum ratio of 4.5 : 1 and enhanced ratio 7 : 1
- Large-scale text (120-150% larger than body text): minimum ratio of 3 : 1 and enhanced ratio 4.5 : 1
- Active user interface components and graphical objects such as icons and graphs: minimum ratio of 3 : 1 and enhanced ratio not defined
Identifying Potential Issues
Sometimes a designer will present a color palette and typography selection in a standalone way as seen in these slides:
When presented this way, it can be difficult to find issues with colors and fonts.
It would be more useful to have colors and fonts presented in the combinations they are likely to be used in on the site.
Encourage your design team to provide real examples of interactive elements and typography. They should also be testing combinations for contrast themselves.
Video Transcript
All right. So let's do some design review. We have some designs that I got from our designer, and we're going to talk through potential accessibility problems in these designs. And the goal of this is to get you thinking about what sorts of things you should be on the lookout for when you're reviewing designs and.
Thinking about like, how can we go and provide feedback in the design phase or that design handoff, hopefully stuff hasn't just been signed off on and sold to a client before anyone gets a chance to review it. But I've done design reviews like this in the real world, and they can be real opportunities to highlight accessibility problems before they get baked into implementations.
So let's do that. Starting with things as basic as colors and typography and for these colors and this presentation, it's a bit hard to say. Like I don't see any obvious issues with the colors. Sometimes there's issues with the like presentation of the designs themselves. What would be more helpful in this presentation is if they had examples of the colors being implemented.
So I could go through and sample these colors check, which combinations would work. If that yellow over white doesn't mean contrast requirements. Like we would need some tips on usage, I think. But there's enough that I could potentially do some testing of colors to get the team thinking about it.
I would probably recommend my team that they find a contrast tool for Figma or whatever design tool they're using, because I think designers could be checking colors too for typography. I don't see a whole lot. There's heading levels. I guess I would probably say something about usage, like making sure that whoever ends up creating things with.
The the patterns or the styles, like making sure that we're choosing headings based on the content and not the style. But as from this graphic, there's not a whole lot that I can really deduce, which, sometimes you don't have much to say. But when you get into things that have interactive components, okay.
Now we have a lot more to talk about. So the first thing is the brand blue. So I would go through and test that on these various backgrounds. Make sure that it's. Enough contrast between the foreground and the background and enough contrast between the white text of say the submit button on the blue background, that subscribe header above the first name and email address, input fields.
Test that color on the gray background. And so sometimes I've gotten the feedback where they're like that's that gray on gray. Like it might be on white, but they showed it to you on gray. So that's something to factor in when you're testing the colors. Do they work on white? I don't think this one would, it looks really faint.
🛠 Challenge: Find Color Contrast Issues
Contrast and color use is vital to accessibility. All of your users, including users with visual disabilities affecting color perception, must be able to perceive content on the page.
In this challenge, your task is to identify contrast and color issues in the following design:
🛠 Solution: Find Color Contrast Issues
The “Subscribe” text fails contrast requirements. The criteria for WCAG 1.4.3 (AA) contrast minimum needs to be 4.5:1, or 3:1 for large text sizes, and this has a contrast ratio of around 2.3:1.
If this was a design for your application, you should request an example with more bold headings and bold text colors.
Even though the contrast ratio for the blue submit button fails to meet 4.5:1, its background color does pass WCAG for non-text contrast against the page background (at least 3:1). Keep in mind there is a different success criterion (1.4.11) that applies to user interface components and graphical objects.
Text inside of user interface components, such as our submit button, still needs to meet the requirements laid out in Contrast minimum (success criterion 1.4.3). Namely, non-large text must be at least 4.5:1 against whatever background it has. But for button text larger than 24 px, it would pass with a ratio of 3:1.
Sampling colors with CCA is a useful way to get early feedback. I recommend that you share this tool with your design team so you can collaborate and learn together.
Video Transcript
- And actually, I'm gonna open up a tool to validate some of this right now. So, we've got our slide. I'm gonna open up a tool. I have installed called CCA or Color Contrast Analyzer. So this CCA application, what I like about it is that it's a standalone application and I can test literally anything on my computer. I could test PDFs, I could test stuff in the web browser. I tested colors in a Zoom meeting recently. That was really cool. I could go and validate colors in the Zoom meeting. It was actually about design systems as well, and so I could give feedback right then, and so I've found this tool to be really helpful. It floats above everything else so it can get a little bit in the way, but I'm gonna use it to sample. So there's a little color picker here. I'm gonna sample this background color and then I'm gonna take the foreground color and sample the gray on the subscribe, and that fails contrast requirements. So the criterion for contrast minimum of 1.4.3 is supposed to meet 4.5:1. And this has a contrast ratio of 2.3:1 if they were like, "Oh, but it's meant to be on white." I could check that, too. All white, that still fails. It has 2.4:1. So I would request that they have more bold headings, bold text colors. So for the blue, I've got a white, let's see white foreground color for the Submit text. And then the background color, I can go and check the blue, and that fails as well. It's only 2.3:1. So it fails both the Level A and the AAA I think this actually falls under non-text contrast 'cause it's a interactive button even though it has text in it. We could go and read up on non-text contrast versus text. I know that one, even if this did qualify as non-text contrast, it still has to be 3:1. And this is only 2.3:1. So it doesn't meet any of these requirements for contrast. So the brand blue would be something that we would need to give feedback on. And I am going to close CCA, go back into full screen so we can look at more of this up close. So we've got some contrast issues that when we're collaborating with designers, like the earlier we can give them that feedback, the better. And so sampling colors that can be useful. The CCA, being a free tool, it's really great to recommend 'cause you're a design team. Like, we can collaborate and learn how to use it together and hopefully they can check stuff themselves 'cause that's the ideal, is if I'm coming in and I happen to notice like sometimes my eyes, I've trained pretty well to just be able to tell whether something isn't passing contrast, passing that skill on to your design team can be so helpful 'cause it can empower them to be thinking about this earlier. And hopefully, they adopt it as a requirement of their job as well 'cause it really is. So reading up on contrast. So non-text contrast would cover things like these switches, little toggle buttons, check boxes. So that blue color would need to improve 'cause it doesn't meet the 3:1 requirement.
🛠 Challenge: Find Iconography & Label Issues
The following challenge requires you to identify one overarching issue with iconography in the design system and another major issue with text labels.
You don’t need any tools for this challenge.
The objective is to identify the issues and discuss your expectations of what you would implement as a developer or communicate with a design team.
The image of the design system is provided below:
🛠 Solution: Find Iconography & Label Issues
An issue that you might identify is that it is unclear what some of these buttons in the toolbar are for. The looking glass icon button is highlighted and then an extra menu pops up. I would recommend talking through that interaction and just making sure that the way you would implement it as a developer aligns with the intended purpose and accessibility is considered. The argument often is that icons are intuitive but sometimes the purpose of an icon is not clear.
There is also an issue with showing additional controls on focus, which we discussed in the previous section on interactions and affordances.
Iconography really benefits from text labels to be accessible and universally understood.
Labels display text throughout the interface. Adding labels to buttons, menu items, and views helps people understand the current context they are in and what they can do next. Clear text labels are essential to the overall accessibility of a design system.
There is also another issue with the subscribe form along with the contrast issues we discussed already.
The form uses placeholders as labels, which means as soon as the user types a field there’s no indication of what it’s for.
Having a persistent text label above each input would make this form more accessible from a cognitive perspective.
Video Transcript
These don't have any text labels, so these icons, not having any way to describe what they are in text. Like, often, I'll see folks add a tool tip or something that, when you hover over them, it explains what they are. And while helpful, it still requires you to hover over it. And so, having an option, at the very least, if it's an application that lives on for a long time, maybe you can add an accessibility preference or something to like, or even just a general preference. I've seen different, on Apple's Finder, they do this. Or maybe in Photoshop or something, you can change the style of the graphic icons to either show text or not. That would be some feedback I would give here that it's unclear what some of these buttons are for. And I think the argument, often, is that they're intuitive. Just click it and find out. But, sometimes, they're not that intuitive, or it's not clear what's interactive or not. So if we, looking at the toolbar, for example, there's the looking glass button is highlighted, and then there's an extra menu that pops up. So, it's one button that launches two buttons. Probably, talking through the interaction of that, and just making sure that the way that you would implement it, as a developer, would align with the intended purpose. So, asking questions about what does this thing do, and that's often what I'm doing to try and figure out if my coding implementation is going to, if I even know what I'm supposed to do with it. Figuring out anything that we can talk about with interaction design and making that accessible. We got a comment that it could be confused between Search and Zoom. Yeah, definitely. So this looking glass, definitely used for Search, as well as Zoom. So yeah, that could be unclear what it's for. I think, pushing for little text labels could be helpful. I think going down below, where it says, "Contact property," and there's two buttons and the Location, so there's an icon on Location, but it doesn't look interactive necessarily. The whole line might be interactive, but the line above it has two buttons. So, a question I would ask is, "Are those buttons on Contact property always visible? Or, is this some kind of hover in the design situation where they're gonna show these on hover?" I would try and talk 'em out of it, . Make the buttons show all the time. And hopefully, maybe there's a way to add labels to them or something. They definitely need text labels under the hood. So if we decided on iconography and the buttons alone, they at least need screen reader labels, but putting a visible label for everyone can definitely help. So talking through your expectations, what you are going to implement as a developer, that's a great time to talk about it, so that you're on the same page. And if you need to change anything that you have their ear or their attention, right at that right time. I guess one more thing before we move on to the next one. Back to the form over here, the Subscribe form uses placeholders as labels. So, first name and email address. They're really faint. So the contrast of those is pretty low. But also, when I go to type in that field, it's probably gonna clear out that placeholder and I'll be like, "What am I typing again?" And so, adding visible, persistent labels to those form inputs, probably above each input, would be very helpful as well. So I would try and talk 'em into that. And yeah, any number of these items could be candidates for getting in front of users, yeah. Which can be challenging. Sometimes, they're like trying to move fast. Don't have the budget. Whatever the excuses are. And so, providing really compelling reasoning can help work around that sometimes. Any input you can get on why we want to not use placeholders as labels, for example. Okay, so a lot to talk about here with this one page of examples.
🛠 Challenge: Find Content Layout Issues
The following content layouts are an example of what a rich article editing experience would look like.
The front layout is the rendered version of an article.
There is a heading & subheadings and three Calls To Action (CTAs) over a photograph.
The layout behind contains the article editor. It has components to add text and upload images.
Your challenge is to identify possible issues with these two layouts and discuss your expectations of what you will implement as a developer or communicate with a design team.
🛠 Solution: Find Content Layout Issues
Here are a couple of examples of issues you could identify.
For the rendered version of the article, it would be unclear to users if the three boxes are static content or if they are interactive. Some subtle treatments could be added to make it more evident that they are interactive, without relying on a hover and focus state to indicate as such.
The editor layout contains several contrast issues. Testing and increasing the contrast of this main heading, subheading, and the H1 would be beneficial. All of these texts look very faint.
In the placeholder images section, there should be a means to describe the content to someone who can't see the screen. For example, what actions do these clickable placeholders represent? Is there a number? “Upload image one of five” could be an example, added in label text for each one and/or by structuring the markup in an HTML ordered list. While this might seem like more of an engineering detail, it can still help to discuss the semantic structure with your design team to look for additional access opportunities.
Collaborating, providing feedback, and influencing design earlier in the process saves you from trying to shoehorn fixes later in the development cycle.
Video Transcript
Here's another one. So some more layout type designs. It's a rich article editing experience with two layouts shown on top of each other. So like the rendered. Version which has three, it's got the heading over a photograph, subheading and main heading. And then these three kind of calls to action here, but it's very unclear that they would be interactive except that the design shows a little hand cursor.
I guess my feedback to the designer there would be like, how can we make these look more interactive? Because they just look like they're part of the layout and they don't immediately look like things that you could click on. I think the expectation is ah, just go figure it out, just go click it.
But maybe there's some subtle treatments that could be added like a little carrot icon or underlining the text, something to make these more obvious that they are actually interactive would be very helpful. I would also go and test the color contrast of anything. The text over the photograph, talk through what happens if it's user generated content and the text isn't visible over the image anymore because of whatever colors are in the image.
Adding some kind of an outline to the text or some treatment to future-proof user generated content could be helpful. Testing the contrast of this heading down here that looks a little faint. Behind that layout, there's a rich editor that has lots of issues. So very poor contrast on everything, all the headings.
There's a toolbar kind of similar to what we saw on the previous screen. So we've already looked at that. But definitely the contrast needs to be bumped up. And yeah, I think there's. Potentially more accessibility issues. It's a little hard to see cause we, we don't have the whole screen. But contrast at the very least, and then some of the ways that we would implement it, like there's a row of images like placeholders where the images will go.
I think how we label those under the hood for a screen reader user would be important. So like upload image, one of five or however many, there are, putting a descriptive label that will describe. To someone who can't see the screen, what actions they will be taking to they're going to upload something by clicking that there are five of these items, maybe they're wrapped in a list or something.
So the items are automatically counted, but we don't want to have the exact same label for every single one of these buttons. Cause. Doing different things. So uploading button to a five even if it's redundant with an unordered list that it might be marked up in, we still want to be thinking about our button controls and how they fit into the rest of the page.
Yeah, there's lots of stuff that we could give feedback on with designs and any of these pieces that you can influence earlier would be so awesome. Cause then you're not trying to shoehorn in fixes later that either get shot down or just don't look as well designed as I could. It's I think that's where collaborating can be really powerful.
Your design colleagues might have that sense of style and aesthetic that, if you put your heads together and you really push them on accessibility, like you could come up with something really beautiful and interactive. And so trying to think of it in those terms, it can be hard there's personalities at play and different constraints and things, but like the ideal would be if you could just try and elevate everyone's game to get the best outcome.
So try and keep that in mind. That's where we want to get to.